宿主|放入_定制.NET6.0的依赖注入

篇首语：本文由编程笔记#小编为大家整理，主要介绍了定制.NET 6.0的依赖注入相关的知识，希望对你有一定的参考价值。

本章是《定制ASP NET 6.0框架系列文章》的第三篇。在本章&＃xff0c;我们将学习ASP.NET Core的依赖项注入&＃xff08;DI&＃xff09;以及如何自定义它。
我们将讨论以下主题&＃xff1a;

• 使用不同的DI容器

• 探索ConfigureServices方法

• 使用其他的ServiceProvider

• Scrutor简介

技术准备

我们使用以下命令&＃xff08;你可以在console, shell,或Bash终端&＃xff09;&＃xff0c;创建一个MVC应用&＃xff1a;

dotnet new mvc -n DiSample -o DiSample

在Visual Studio中打开项目&＃xff0c;或在控制台中键入以下命令&＃xff0c;在Visual Studio Code中打开项目&＃xff1a;

cd DiSample
code .

使用不同的DI容器

在大多数项目中&＃xff0c;我们其实不需要使用不同的DI容器。ASP.NET Core中的现有DI基本上满足我们的需要。但是&＃xff0c;你可能喜欢其他DI容器的其他功能&＃xff1a;

• 使用Ninject创建一个支持模块作为轻量级依赖项的应用程序。比如&＃xff0c;您可能希望将模块放入特定目录中&＃xff0c;并在应用程序中自动注册这些模块。

• 在应用程序外部的配置文件中&＃xff0c;比如&＃xff0c;在XML或JSON文件中&＃xff0c;而不是仅在C#中配置服务。这是各种DI容器中的常见功能&＃xff0c;但ASP.NET Core中尚不支持。

• 在运行时添加服务&＃xff0c;获取动态的DI容器&＃xff0c;这也是一些DI容器中的常见特性。

现在&＃xff0c;让我们看看ConfigureServices方法是如何操作的。

探索ConfigureServices方法

我们将当前的ConfigureServices方法与以前的长期支持版本&＃xff08;TLS&＃xff09;进行比较&＃xff0c;看看有什么变化。如果您使用版本3.1创建的ASP.NET Core项目&＃xff0c;并打开Startup.cs文件&＃xff0c;配置服务的方法如下所示&＃xff1a;

public void ConfigureServices(IServiceCollection services)
    services.Configure(options &＃61;>
    
         options.CheckConsentNeeded &＃61; context &＃61;> true;
    );
    services.AddControllersWithViews();
    services.AddRazorPages();


相反&＃xff0c;在 ASP.NET Core 6.0&＃xff0c;没有启动Startup.cs&＃xff0c;服务的配置在Startup.cs中进行&＃xff0c;如下所示&＃xff1a;

var builder &＃61; WebApplication.CreateBuilder(args);
// Add services to the container. builder.Services.AddControllersWithViews();
var app &＃61; builder.Build();
// The rest of the file isn&＃39;t relevant for this chapter

这两种情况都可以获得IServiceCollection&＃xff0c;其中默认已经填充了ASP.NET Core所需的一组服务&＃xff0c;比如宿主服务、ConfigureServices方法之前执行的相关服务。
以上方法中&＃xff0c;添加了更多的服务。

• 首先&＃xff0c;将包含COOKIE策略选项的配置类添加到ServiceCollection。

• AddMvc()方法添加MVC框架所需的服务。
  到目前为止&＃xff0c;我们有大约140个服务注册到IServiceCollection。
  但是&＃xff0c;服务集合不是实际的DI容器&＃xff0c;真实的DI容器被包装在所谓的服务提供者中&＃xff08;ServiceProvider&＃xff09;。

那么应该如何获取DI容器呢&＃xff1f;

IServiceCollection有了一个扩展方法&＃xff0c;它用于从服务集合中创建IServiceProvider&＃xff0c;代码如下&＃xff1a;

IServiceProvider provider &＃61; services.BuildServiceProvider()

ServiceProvider包含不可变容器&＃xff0c;即在运行时无法更改。在ConfigureServices方法执行后&＃xff0c;会在后台创建IServiceProvider。
接下来&＃xff0c;我们再看下如何在DI定制过程中&＃xff0c;替代IServiceProvider。

使用其他IServiceProvider

如果其他容器已经支持ASP.NET Core&＃xff0c;则更改为其他或自定义DI容器将变得非常容易。通常&＃xff0c;第三方DI容器会使用IServiceCollection做为自己的容器&＃xff0c;它通过循环集合将已注册的服务移动到另一个容器。
我们用第三方容器Autofac举个例子。在命令行中键入以下命令,加载NuGet包&＃xff1a;

dotnet add package Autofac.Extensions.DependencyInjection

要注册自定义IoC容器&＃xff0c;通常需要注册不同的IServiceProviderFactory&＃xff0c;IServiceProviderFactory将创建一个ServiceProvider实例。如果第三方容器支持ASP.NET Core&＃xff0c;则必须提供一个该工厂类。如果你要使用Autofac&＃xff0c;则需要使用AutofacServiceProviderFactory。

我们在Program.cs中给IHostBuilder编写一个扩展方法&＃xff0c;内部注册一个AutofacServiceProviderFactory&＃xff1a;

using Autofac;
using Autofac.Extensions.DependencyInjection;
namespace DiSample;
public static class IHostBuilderExtension      public static IHostBuilder UseAutofacServiceProviderFactory(this IHostBuilder hostbuilder)
          
hostbuilder.UseServiceProviderFactory (new AutofacServiceProviderFactory());          return hostbuilder;     



注意&＃xff0c;不要忘记将引入名称空间&＃xff1a;Autofac和Autofac.Extensions.DependencyInjection。
要使用此扩展方法&＃xff0c;可以在Program.cs中使用AutofacServiceProvider&＃xff1a;

var builder &＃61; WebApplication.CreateBuilder(args);
builder.Host.UseAutofacServiceProviderFactory();
// Add services to the container. builder.Services.AddControllersWithViews();

以上通过扩展方法将AutofacServiceProviderFactory添加到IHostBuilder中&＃xff0c;并启用AutofacIoC容器。后续会转而使用Autofac向IServiceCollection添加服务。
再强调一下&＃xff0c;除非必要。通常&＃xff0c;我们不一定要替换现有的.NET CoreDI容器。

Scrutor简介

在本章的开头&＃xff0c;我提到了服务的自动注册&＃xff0c;这里可以通过其他DI容器完成。这里介绍一个名为Scrutor的不错的NuGet包来实现。
Scrutor通过向.NET Core DI容器向IServiceCollection添加一个扩展方法&＃xff0c;用以自动注册服务。

扩展阅读
这里介绍一篇关于Scrutor的非常详细的博客文章&＃xff0c;建议您继续阅读这篇文章以了解更多信息。

回顾

通过以上演示&＃xff0c;我们将能够使用任何.NET标准兼容的DI容器替换现有容器。如果您选择的容器不包括ServiceProvider&＃xff0c;请自己实现一个IServiceProvider接口&＃xff0c;并在其中使用DI容器。如果您选择的容器没有提供填充服务的方法&＃xff0c;请自行创建自己的方法。循环已注册的服务并将其添加到另一个容器中。
最后一步听起来很简单&＃xff0c;实现起来比较费劲&＃xff0c;因为需要将所有的IServiceCollection注册转换为其他容器的注册&＃xff0c;它的复杂性取决于其他DI容器的实现细节。
任何时候&＃xff0c;我们都可以选择使用任何与.NET标准兼容的DI容器&＃xff0c;替换ASP.NET Core中的许多默认实现。
在下一章我们将探讨如何以不同的方式配置HTTPS&＃xff0c;感谢您的阅读。